During the last few years, considerable developments have been made in the arena of server management. An industry standard called Intelligent Platform Management Interface (IPMI), described in, e.g., “IPMI: Intelligent Platform Management Interface Specification, Second Generation,” v.2.0, Feb. 12, 2004, defines a protocol, requirements and guidelines for implementing a management solution for server-class computer systems. The features provided by the IPMI standard include power management, system event logging, environmental health monitoring using various sensors, watchdog timers, field replaceable unit information, in-band and out of band access to the management controller, SNMP traps, etc.
A component that is normally included in a server-class computer to implement the IPMI standard is known as a Baseboard Management Controller (BMC). A BMC is a specialized microcontroller embedded on the motherboard of the computer, which manages the interface between the system management software and the platform hardware. The BMC generally provides the “intelligence” in the IPMI architecture.
Most server-class computer systems on the market today have system components that require a firmware image to make them operational. “Firmware” is software that is stored in a read-only memory (ROM) (which may be reprogrammable), such as a ROM, PROM, EPROM, EEPROM, etc. Some examples of such components that require firmware are BMCs, the system basic input/output system (BIOS), storage controllers (e.g., SCSI/SAS/Fibre Channel components), and network interface controllers (NICs). These firmware images typically reside in the system flash memory where the BIOS resides or in component-specific flash parts.
As with any software, these firmware images can become obsolete, can become corrupted or may contain bugs (the latter two cases can be collectively referred to as “faults”). Therefore, a method is needed to update firmware images in a computer system as and when necessary. In this context, firmware “update”, firmware “download” and firmware “flashing” all have the same meaning and generally refer to a process in which a firmware image obtained from some distribution media, is placed permanently in some location in the motherboard or associated peripherals of the system.
A typical approach to updating firmware involves booting the machine being updated to a service operating system (OS), such as DOS or Linux. A standalone application that knows the software and hardware intricacies of flashing that particular firmware image is then run on that service OS, accepting a firmware image and flashing it. A significant disadvantage of using such a method is that it typically requires user intervention in the form of keyboard input and/or presentation of the image, possibly at the same location as the system being updated. In addition, the service operating system may not be the same as the one normally run on the hardware, forcing the normal function of the hardware to be interrupted. For certain types of systems, this would cause down time, which may be extremely undesirable, such as in enterprise class storage servers.
Another known approach to updating firmware involves using a technique known as Serial-over-LAN (SOL) to allow a BMC to communicate with a remote management application, to update the BIOS firmware of the host computer. With this approach, a serial port of the server is remapped so that all outgoing communications directed to that serial port are routed over the server's LAN interface. The BMC then uses the serial port to communicate with the remote application, via a LAN.
A disadvantage of this SOL technique is that it requires that someone set up a serial YMODEM host at the remote end of the network, which tends to be a relatively complex operation. Another disadvantage of the SOL technique is that firmware other than BIOS cannot be updated using SOL without a host OS operating normally on the system that is being updated (not in its startup or shutdown mode). Yet in certain situations, it may be desirable or necessary to install new firmware while the host OS is not operating normally (or at all), such as after a system crash. This may be the case if, for example, faulty firmware is what is causing the OS to crash. At the least, this technique may require a reboot of the host OS, which results in undesirable down time. In addition, it is believed that the SOL approach has been limited to updating BIOS firmware, not other types of firmware.
Therefore, what is needed is a technique to install firmware in a processing system, which overcomes these disadvantages.